when encountering bug 1480452 I expect to see the about:restartrequired page but do not. this may be a recent regression. testing on win10 nightly

In particular, instead Asa is seeing an endless throbber in the tab, and a blank page that never loads. The tab's tooltip provides a PID, which shows up in about:processes associated with the right site (fission is enabled), but taking 0B of memory and idle CPU.

In Slack, Asa said: "Windows task manager does not show the process even though Firefox shows the process in the tab and about:processes" which is peculiar.

(In reply to Andrew McCreight [:mccr8] from comment #2)

In Slack, Asa said: "Windows task manager does not show the process even though Firefox shows the process in the tab and about:processes" which is peculiar.

My suspicion is that we launch the process and it exists in our parent-process admin stuff, but then the process exits (because it detects it's newer than the parent process, because the bits on disk have changed but the parent process is "old"). Is that plausible?

Yes, it is probably something like that. I don't know how the parent tracks when the child exits, so I'm not sure why it is missing it here. Maybe it is dying very early before the parent properly sets up watching for the process exit?

Nick, is there a meta bug for "update while running" issues that I can link this bug to?

(In reply to Chris Peterson [:cpeterson] from comment #5)

Nick, is there a meta bug for "update while running" issues that I can link this bug to?

There are two related issues: Bug 1480452 and Bug 1705217. The first one has a long comment explaining the current state of the world.

(In reply to Nick Alexander :nalexander [he/him] from comment #6)

(In reply to Chris Peterson [:cpeterson] from comment #5)

Nick, is there a meta bug for "update while running" issues that I can link this bug to?

There are two related issues: Bug 1480452 and Bug 1705217. The first one has a long comment explaining the current state of the world.

Having re-read that comment, I'm still confused about this bug - the issue here is that there is no warning, and instead Firefox is just "useless" as it fails to load any new pages, but doesn't inform the user about what is broken (which is arguably much worse!). Do you have any suggestions on how to debug this further and/or who would know? :-)

(In reply to :Gijs (he/him) from comment #7)

(In reply to Nick Alexander :nalexander [he/him] from comment #6)

(In reply to Chris Peterson [:cpeterson] from comment #5)

Nick, is there a meta bug for "update while running" issues that I can link this bug to?

There are two related issues: Bug 1480452 and Bug 1705217. The first one has a long comment explaining the current state of the world.

Having re-read that comment, I'm still confused about this bug - the issue here is that there is no warning, and instead Firefox is just "useless" as it fails to load any new pages, but doesn't inform the user about what is broken (which is arguably much worse!). Do you have any suggestions on how to debug this further and/or who would know? :-)

I intended those two issues to be "the place to hang things about updating while running". This specific bug appears, at first blush, to be specific to detecting and/or displaying that a restart is required (and not really about the mechanics of updating).

The folks who know most are jld and jesup, AFAIK. I'll NI jld to see if he has thoughts on what might have changed here.

(In reply to Andrew McCreight [:mccr8] from comment #4)

Yes, it is probably something like that. I don't know how the parent tracks when the child exits, so I'm not sure why it is missing it here. Maybe it is dying very early before the parent properly sets up watching for the process exit?

This (+ the fact that it's on Windows) reminded me of bug 1488990, which could cause what's observed here if the process crashes after being created but before initializing IPC.

I don't know exactly why it would crash before IPC due to a version mismatch with the parent (assuming the new install started correctly); the sandbox does some weird stuff, and then there's our monitoring/control over injected third-party modules which I don't understand in detail. I assume our own crash reporter wouldn't be able to help, but maybe Windows Error Reporting can get useful information? But the exact reason may not matter much, compared to the observation that it can happen.

When I filed bug 1488990 I was thinking of adding a timeout, which means setting it high enough to avoid false positives; that's not an ideal solution, but it would be an improvement (and would also cover hangs in early startup; probably less likely, but we have had that happen on Linux). It would also make sense to monitor the child process's status and detect termination directly, but that's a larger task (and I have some less radical cleanup in bug 1658072 which would make sense to finish first).

From comment 0 and comment 1, sounds like what is described in bug 1788173